Monitoring workflow timing information related to http requests to web servers

ABSTRACT

Described herein are systems, methods, and software to manage workflow monitoring between a client and one or more web servers. In one implementation, a client may initiate a workflow and maintain timing information associated with HTTP requests to one or more web servers as part of the workflow. The client further obtains, from the one or more web servers, log information for operations initiated from the HTTP requests to the one or more web servers and generates a timing diagram display based on the timing information and the log information.

RELATED APPLICATIONS

This application hereby claims the benefit of and priority to U.S. Pat.Application No. 17/568,147, titled “MONITORING WORKFLOW TIMINGINFORMATION RELATED TO HTTP REQUESTS TO WEB SERVERS,” filed Jan. 4,2022, and which is hereby incorporated by reference in its entirety.

TECHNICAL BACKGROUND

Software workflows, which can include software wizards, are userinterfaces that can present a user with a sequence of steps that canlead a user to implement a desired operation. The workflows can be usedto configure an application, install an application, configure virtualnetworks or a set of one or more virtualized endpoints, or provide someother operation. For example, a workflow may provide a user with asequence of steps to configure a cluster of virtual machines.

In implementing the operations for the workflow, the workflow may useHTTP requests to communicate with one or more web servers. The HTTPrequests may be used to request information from the server, provideinformation to the server, delete information from the server, orprovide some other operation. For example, an HTTP request may comprisea “PUT” request to replace a target resource with uploaded content.

However, while software workflows can provide users with steps toimplement desired operations, difficulties arise for developers intesting and monitoring the different workflows. Specifically, developersmay have difficulties in identifying problems in HTTP requests, such aslatency or delay, when a workflow is executed. These problems may occurin the communication of the HTTP request to the web server, the responseto the HTTP request by the web server, implementing the methods in theweb server, or at some other instance during the execution of theworkflow. These problems can further be compounded when a workflowrequires a large quantity of HTTP requests or requests to multiple webservers.

SUMMARY

The technology described herein manages workflow timing informationrelated to HTTP requests to web servers. In one implementation, a clientsystem identifies a request to monitor a workflow in the client systemand, in response to the request, maintains timing information associatedwith HTTP requests to one or more web servers in association with theworkflow, wherein the timing information comprises at least timestampsassociated with initiating each of the HTTP requests and receivingresponses to each of the HTTP requests. The client system furtherobtains, from the one or more web servers, log information foroperations initiated from the HTTP requests to the one or more webservers, wherein the log information comprises at least timestampsassociated with starting each of the operations and ending each of theoperations. Once obtained, the client system generates, for display, atiming diagram, wherein the timing diagram indicates times forinitiating each of the HTTP requests and receiving responses to each ofthe HTTP requests, and wherein the timing diagram further indicatestimes for starting each of the operations and ending each of theoperations.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a timing diagram associated with a workflow and HTTPrequests associated with the workflow according to an implementation.

FIG. 2 illustrates a computing environment to monitor timing informationassociated with HTTP requests for a workflow according to animplementation.

FIG. 3 illustrates a method of operating a client system to monitortiming information associated with HTTP requests for a workflowaccording to an implementation.

FIG. 4 illustrates a diagram of managing timing information associatedwith a workflow according to an implementation.

FIG. 5 illustrates a computing system to monitor timing informationassociated with HTTP requests for a workflow according to animplementation.

DETAILED DESCRIPTION

FIG. 1 illustrates a timing diagram 100 associated with a workflow andHTTP requests associated with the workflow according to animplementation. Timing diagram 100 includes workflow process 110, HTTPrequests 120-121, web server controllers 130-131, and methods 140-141,which is representative of information that can be provided as a userinterface to a developer. Timing diagram 100 further includes clienttiming information 150-151, web server timing information 160-161 andtime axis 170.

In developing a workflow for users of a software application, developersmay desire to monitor timing information associated with a userinteracting with the workflow. For example, a workflow may comprise asoftware wizard that can be used to configure one or more virtualizationendpoints (e.g., virtual machines, containers, and the like), configurenetworking for one or more virtualization endpoints, configure one ormore applications (web based or local), or some other workflowoperation. Although described as a software wizard, a workflow canrepresent any set of events in association with an application. Theevents may comprise user feedback, such as clicking, selecting from aset of options, or some other event that corresponds to a set ofactions. For example, a workflow may comprise a set of operations thatare used to configure a cloud service in one or more virtual machines.In some implementations, the workflows may require HTTP requests to oneor more web servers to implement the desired operations. The HTTPrequests may be used to retrieve information from the web server,communicate information to the web server, delete information from theweb server, or provide some other operation in association with the webserver.

Here, a user initiates workflow process 110 at a client system, whereinthe client system may comprise a physical computing system, a virtualmachine, or some other client system. Workflow process 110 may beinitiated in a browser or may comprise a standalone application in someexamples. A user initiating workflow process 110 may indicate theworkflow to be monitored in some examples, wherein the user may identifya start and end point of the workflow to dictate the monitoredinformation associated with the workflow. For example, the user mayindicate that workflow process 110 comprises a software wizard toconfigure one or more virtual machines in a virtual network. When theuser starts the workflow, by providing a user interaction to start theworkflow (e.g., starting the wizard), the client system may initiate amonitoring operation to maintain timing information associated with HTTPrequests associated with workflow process 110. Specifically, the clientsystem may maintain client timing information 150-151 that correspondsto HTTP requests 120-121 and workflow process 110, wherein the timinginformation may include identifying when each of the HTTP requests isinitiated and when each of the HTTP requests are completed or havereceived a response to the request.

In addition to maintaining the local client timing information 150-151,each of the web servers used in the workflow may also maintain loginformation associated with the HTTP requests to the web servers.Specifically, each of the web servers may log information associatedwith initiating and completing various operations, including controlleroperations, methods, or some other timing information associated withprocessing the HTTP request at the web server. Using the example, ofHTTP request 120, the web server associated with the request maintainsweb server timing information 160 as a log that includes timinginformation associated with web server controller 130 and method 140.The start time associated with web server controller 130 may occur whenthe HTTP request is received, and the end time may correspond to whenthe controller provides a response to the request or ends operationsassociated with the request. Additionally, method 140 may represent astart and end time for a method initiated from the web controller,wherein the method may post data to the web server, retrieve data fromthe web server, replace data in the web server, or provide some otheroperation at the web server. Although demonstrated with a single method,multiple methods can be initiated from a single HTTP request. Forexample, method 140 may initiate one or more additional methods and theweb server may maintain a log that indicates start and stop timesassociated with each of the methods. The methods may be used to postdata to the web server, retrieve data from the web server, replace datain the web server, or provide some other operation at the web server. Insome implementations, these methods may execute longer than the workflowprocess or the HTTP request itself. For example, while the HTTP requestmay be completed following a response from the web server, one or moremethods may continue executing in the web server to support theoperation.

In addition to web server timing information 160, the same web server oran additional web server may maintain web server timing information 161associated with HTTP request 121. Specifically, web server timinginformation 161 may correspond to start and end times associated withweb server controller 131 and method 141. Again, while demonstrated withexecuting a single method, multiple methods can be initiated in responseto the HTTP request.

After completing workflow process 110, the client system obtains the webserver timing information 160-161 from the one or more web servers anduses the information to generate a timing diagram display of the timinginformation associated with workflow process 110. Web server timinginformation 160-161 may comprise one or more logs in some examples thatindicate the timing information associated with starting the web servercontrollers and the methods. The display may include times associatedwith client timing information 150-151, as well as web server timinginformation 160-161. In the example of timing diagram 100, the times aredisplayed as tiers and correspond to the start and end times of theworkflow process 110, HTTP requests 120-121, web server controllers130-131, and methods 140-141.

In some examples, the client system may identify one or more operationsof interest at the web servers based on the web server timinginformation 160-161, wherein the operations may comprise the controlleroperations or method operations. The operations of interest may occurwhen an operation executes for longer than a defined period, shorterthan a defined period, or for some other factor satisfying at least onecriterion. Other operations of interest may occur when comparing acurrent execution of the workflow with a previous execution of the sameworkflow and identifying differences between the operations in thecurrent workflow and the previous execution of the workflow.Additionally, operations of interest may comprise latencies associatedwith generating the HTTP request and the web server controller beinginitiated, latencies associated with initiating the one or more methodsfrom the controller, or some other latency associated with the HTTPrequests to the one or more web servers. The operations of interest maybe identified when any timing attribute (latency, length, and the like),satisfies criteria (e.g., maximum length of time) for an operation ofinterest. In at least one implementation, when an operation of interestis identified, the operation of interest may be promoted in the timingdiagram, wherein the promotion may include highlighting, increasing thesize, bolding, or providing some other promotion of the operation ofinterest in relation to other operations in the timing diagram.

In some implementations, the client system may identify one or more HTTPrequests of interest based on the log information from the one or moreweb servers or the maintained timing information at the client. The HTTPrequests of interest may be identified based on the duration of the HTTPrequest exceeding a threshold duration, based on the HTTP requestfalling below a threshold duration, or some other factor. In someimplementations, the HTTP requests of interest may be identified basedon latency associated with communicating the request to and from the webserver, may be identified based on a comparison of the duration of therequest to previous iterations of the workflow (e.g., a duration of theHTTP request during a first iteration of the workflow to a secondduration of the HTTP request during a second iteration of the workflow),based on changes in the methods performed as part of the workflowcompared to previous iterations of the workflow, or some other factor.The HTTP requests of interest may be identified when an HTTP request ofinterest satisfies one or more criteria, such as a threshold (e.g.,duration of a HTTP request). When a HTTP request of interest isidentified, the timing diagram may promote the HTTP request in relationto other HTTP requests in the timing diagram. The promotion may includeincreasing the size, highlighting, generating a flag, or otherwisepromoting the HTTP request of interest over other HTTP requests as partof the workflow. The promotion may also provide a summary or anindication of what triggered the HTTP request to be identified as arequest of interest.

Although not demonstrated in the example of timing diagram 100, theclient may further maintain information about the user feedbackassociated with the workflow. The user feedback may include selectionsby the user that can trigger one or more HTTP requests. From the userfeedback information, the client may identify one or more of the userinteractions in the timing diagram and may demonstrate the HTTP requeststhat occur because of the selection.

Although described herein using HTTP requests, requests using any typeof network protocol can be monitored. The requests may comprise FileTransfer Protocol (FTP) requests, Transmission Control Protocol (HTTP)requests, or some other network protocol request in a workflow. Forexample, an application may generate a TCP request to obtain data from aserver, wherein the client generating the request and the server mayeach maintain timestamp information associated with the request. Theclient may monitor the timestamps of generating the TCP request and theTCP response, while the server may monitor timestamps associated withexecuting one or more methods or services at the server to support therequest. The server may then provide information back to the client tosupport the generation of the summary.

FIG. 2 illustrates a computing environment 200 to monitor timinginformation associated with HTTP requests for a workflow according to animplementation. Computing environment 200 includes client 210 and server211. Client 210 includes workflow monitoring service 260, workflow 220,and network interface (NIC) 250. Server 211 further includes operations230, logs 235, and NIC 251. Client 210 provides HTTP requests 240 toserver 211 and server 211 provides log information 245 to client 210.

In computing environment 100, workflow monitoring service 260 is used tomonitor information associated with HTTP requests as part of workflow220. Workflow 220 may comprise a software wizard or some other steppedsoftware configuration operation that requires one or more HTTP requeststo provide the desired operation. Workflow 220 may be used to configurean application, configure one or more virtualized endpoints, configurenetworking operations, or provide some other operation. When theworkflow is initiated (i.e., started) by a user at client 210, workflowmonitoring service 260 may monitor or maintain timing informationassociated with HTTP requests 240 to server 211 in association withworkflow 220, wherein the timing information comprises at leasttimestamps associated with initiating each of the HTTP requests. Thetiming information may further comprise timestamps associated withreceiving response to the HTTP requests in some examples.

As the HTTP requests are communicated to server 211, server 211 maymaintain logs 235 that correspond to timing information for operations230 initiated from HTTP requests 240. Operations 240 may includecontroller operations and method operations. The controller operationcan be used to trigger one or more method operations based on the HTTPrequest. The information maintained in logs 235 may include timestampsassociated with starting and ending each of the operations. For example,a method operation initiated as part of an HTTP request may be added tologs 235 to indicate the start time of the operation and the stop timeof the operation.

Log information 245 is then provided back from logs 235 to client 210,permitting client 210 to generate a timing diagram for workflow 220using the locally maintained timing information and log information. Thetiming diagram may indicate times for initiating each of the HTTPrequests to server 211, times for receiving responses to each of theHTTP requests to server 211, times for starting each operation ofoperations 230 at server 211 initiated in response to the HTTP requests,times for ending each operation of operations 230 at server 211initiated from the HTTP requests, or some other information. In someimplementations, the timing diagram may appear as durations associatedwith the HTTP requests and operations initiated from the HTTP requestsas demonstrated in timing diagram 100 of Figure, although other examplesmay exist. In some examples, the timing diagram may indicate the spawnedoperations (controller, method, and the like) spawned from each of theHTTP requests.

FIG. 3 illustrates a method 300 of operating a client system to monitortiming information associated with HTTP requests for a workflowaccording to an implementation. The steps of method 300 are referencedparenthetically in the paragraphs that follow.

In method 300, a client system identifies (301) a request to monitor aworkflow at the client system. The workflow may comprise a softwarewizard in some examples that permits a user to configure an applicationusing a plurality of steps, wherein the steps may require HTTP requeststo one or more web servers. The workflow may be defined by the user insome examples, wherein the user may identify the start and endpoint forthe workflow, such as user input that triggers the start and end of theworkflow. In response to the request, method 300 further maintains (302)timing information associated with HTTP requests to one or more webservers in association with the workflow, wherein the timing informationcomprises at least timestamps associated with initiating each of theHTTP requests and receiving responses to each of the HTTP requests. Forexample, a workflow may require ten HTTP requests to a web server. Foreach of the request, the client system may identify a timestamp for theHTTP request to the web server and may further monitor the timestampsfor when each HTTP request is completed, or a response is returned forthe HTTP request.

In addition to maintaining the timing information at the client system,the client system may further obtain (303), from the one or more webservers, log information for operations initiated from the HTTP requeststo the one or more web servers, wherein the log information comprises atleast timestamps associated with starting each of the operations andending each of the operations. In some implementations each of the webservers may maintain one or more logs that can identify time stampsassociated with operations triggered by the HTTP requests. Theoperations may comprise controller operations or methods initiated fromthe controller, wherein the controller may be used to schedule andinitiate the methods that correspond to the HTTP request. The loginformation may include timestamps for when each operation was initiatedand when each operation was completed. For example, when an HTTP requestis received at the web server, the web server may log a timestamp whenthe HTTP request was received by the controller. Additionally, the loginformation may include timestamps for when each operation concludes orends, which can be used to determine a duration associated with each ofthe operations. In some examples, the log information may be provided tothe client system when workflow concludes, wherein the client system mayrequest and receive the log information from the web server. In otherexamples, the log information may be provided to the client system afterthe completion of one or more of the operations.

In some implementations, when the HTTP request is generated by theclient, identifier information is added in the header of the request tobind or uniquely associate the HTTP request to a correspondingcontroller operation. The identifier information can be used todistinguish each of the HTTP requests originating from the client, suchthat operations initiated for each of the requests can be traced to asingle HTTP request. For example, a first HTTP request may initiate afirst controller operation and a second HTTP request may initiate asecond controller operation. To uniquely identify or associate thecontroller operations to the HTTP requests, an identifier can beincluded in each of the requests, such that the log information can beassociated with each unique request.

After the log information is obtained from the one or more web servers,method 300 further generates (304), for display, a timing diagram,wherein the timing diagram indicates times for initiating each of theHTTP requests and receiving responses to each of the HTTP requests, andwherein the timing diagram further indicates times for starting each ofthe operations and ending each of the operations. In someimplementations, the timing diagram may appear like timing diagram 100represented in FIG. 1 , but other examples may exist. In some examples,each HTTP request may be linked to the corresponding operations at theweb server, wherein dependent operations can be linked to the sourceHTTP request or calling operation. For example, an HTTP request from aclient can be received by a web server initiating a controlleroperation. The controller operation can call a first method and,subsequently, call a second method, wherein each method call bereflected in the timing diagram as originating from the controlleroperation based on the log information provided by the web server. Insome examples, an operation at a web server can execute longer than theworkflow process, wherein a termination event for the workflow processcan occur before a method is terminated at the web server.

In some implementations, the client system may further identify items ofinterest in the timing diagram for the workflow. The items of interestmay correspond to HTTP requests of interest or operations of interest atthe web server. The HTTP requests of interest or operations of interestmay be identified when a request or operation has a duration thatexceeds a threshold, when a request or operation falls below a durationminimum, when the request or operation duration differs from a previousiteration of the workflow by a threshold amount, or some other criteriato identify HTTP requests or operations of interest. As an example, whenthe duration of an HTTP request exceeds a threshold, a flag may begenerated to promote or identify the HTTP request over other HTTPrequests. The promotion of the HTTP request in the timing diagram mayinclude highlighting the corresponding HTTP request, generating anotification for the user requesting the timing diagram, or some otherpromotion of the HTTP request. Similar promotions may be made ofoperations of interest identified.

In some examples, additional information may be provided as part of thetiming diagram. The additional information may include timestampsassociated with user feedback to the workflow, wherein the feedback mayfurther be mapped to one or more HTTP requests that occur in response tothe feedback. The feedback information may be maintained as part of thetiming information at the client system.

FIG. 4 illustrates a diagram 400 of managing timing informationassociated with a workflow according to an implementation. Diagram 400includes client 410 and web servers 420-421. While demonstrated with twoweb servers in the example of diagram 400, any number of web servers maybe used to support the workflow.

As depicted in diagram 400, client 410 initiates, at step 1, a workflowthat can be used to configure an application, configure a virtualcluster, configure a networking configuration, or provide some otheroperation. In some examples, the workflow may comprise a software wizardthat permits a user to follow one or more steps via user feedback toimplement the desired operation. For example, the user may generate userfeedback to provide preferences in association with the workflow,wherein the feedback may trigger HTTP requests to one or more webservers.

After initiating the workflow one or more requests are communicated toweb server 420 and web server 421 at step 2. The HTTP requests may beused to obtain information from the web server, store data to the webserver, or provide some other action in association with the web server.At each of the web servers 420-421, the web servers may maintain loginformation associated with timestamps for operations initiated by theHTTP requests at step 3. As an example, when client 410 generates anHTTP request to web server 420, web server 420 may receive the requestand initiate a controller operation to manage the initiation of methodoperations to support the request. The method operations may alsoinitiate additional methods to support the HTTP request. The timestampsmay include when each of the operations and may further includetimestamps associated with the completion of each of the operations. Thetimestamps may be used to identify a duration of each of the operationsat the web server, including the duration of the controller operationsand the method operations initiated from the controller operations.

As the log information is maintained by each web server of web servers420-421, client 410 may identify an end of the workflow at step 4,wherein identifying the end of the workflow may occur when a userprovides feedback indicating the end of the workflow (e.g., a selectionof a button on the user interface at client 410), may occur when thesoftware wizard of the workflow closes, or may occur based on some otherconclusory event. In response to concluding the workflow, client 410obtains the required log information from web servers 420-421. Althoughdemonstrated as obtaining the log information following the end of theworkflow, at least a portion of the log information may be communicatedback to client 410 prior to the conclusion of the workflow.

After receiving the log information from web servers 420-421, client 410generates, at step 6, a timing diagram indicating the start and endtimes associated with the HTTP requests and the operations at thevarious web servers. Specifically, the timing diagram may use the timinginformation maintained locally by client 410 corresponding to the HTTPrequests and the log information corresponding to the operations at theweb servers to generate the timing diagram. In some implementations, thetiming diagram may indicate start and end times for the HTTP requests aswell as start and end times for the operations at the web servers. Thetiming diagram may indicate the HTTP requests or operations thattriggered each subsequent operation. For example, the timing diagram mayindicate that an HTTP request triggered the execution of a controlleroperation, and the controller operation initiated a method operation atthe web server.

In some implementations, the timing diagram may further promote oridentify HTTP requests of interest or operations of interest based on avariety of factors. These factors may include the duration of the HTTPrequests or operations at the web server exceeding a threshold, theduration of the HTTP requests or operations at the web server differingfrom durations associated with previous executions of the workflow, orsome other factor. When promoting the HTTP request or operation ofinterest, the client may highlight portions of the timing diagramassociated with the HTTP request or operation of interest, the clientmay generate a flag identifying the HTTP request of interest oroperation of interest or may provide some other notification indicatingthe HTTP request of interest or operation of interest.

Although demonstrated in the examples of FIGS. 1-4 as generating thetiming diagram at the client, the timing diagram may be generated atsome other computing system, including a web server in some examples. Inat least one implementation, the timing information from the client andlog information from the web servers may be distributed to anothercomputing system capable of generating the timing diagram. The timingdiagram can then be generated and distributed to the correspondingclient, cached for later viewing on another computing system, orprocessed in some other manner.

FIG. 5 illustrates a computing system 500 to monitor timing informationassociated with HTTP requests for a workflow according to animplementation. Computing system 500 is representative of any computingsystem or systems with which the various operational architectures,processes, scenarios, and sequences disclosed herein for a client systemcan be implemented. Computing system 500 is an example of a client 210of FIG. 2 , although other examples may exist. Computing system 500includes storage system 545, processing system 550, and communicationinterface 560. Processing system 550 is operatively linked tocommunication interface 560 and storage system 545. Communicationinterface 560 may be communicatively linked to storage system 545 insome implementations. Computing system 500 may further include othercomponents such as a battery and enclosure that are not shown forclarity.

Communication interface 560 comprises components that communicate overcommunication links, such as network cards, ports, radio frequency (RF),processing circuitry and software, or some other communication devices.Communication interface 560 may be configured to communicate overmetallic, wireless, or optical links. Communication interface 560 may beconfigured to use Time Division Multiplex (TDM), Internet Protocol (IP),Ethernet, optical networking, wireless protocols, communicationsignaling, or some other communication format - including combinationsthereof. Communication interface 560 may be configured to communicatewith one or more web servers and other computing systems via one or morenetworks.

Processing system 550 comprises microprocessor and other circuitry thatretrieves and executes operating software from storage system 545.Storage system 545 may include volatile and nonvolatile, removable, andnon-removable media implemented in any method or technology for storageof information, such as computer readable instructions, data structures,program modules, or other data. Storage system 545 may be implemented asa single storage device but may also be implemented across multiplestorage devices or sub-systems. Storage system 545 may compriseadditional elements, such as a controller to read operating softwarefrom the storage systems. Examples of storage media include randomaccess memory, read only memory, magnetic disks, optical disks, andflash memory, as well as any combination or variation thereof, or anyother type of storage media. In some implementations, the storage mediamay be a non-transitory storage media. In some instances, at least aportion of the storage media may be transitory. In no case is thestorage media a propagated signal.

Processing system 550 is typically mounted on a circuit board that mayalso hold the storage system. The operating software of storage system545 comprises computer programs, firmware, or some other form ofmachine-readable program instructions. The operating software of storagesystem 545 comprises timing service 530 and workflow 532. The operatingsoftware on storage system 545 may further include an operating system,utilities, drivers, network interfaces, applications, or some other typeof software. When read and executed by processing system 550 theoperating software on storage system 545 directs computing system 500 tooperate as described herein. In at least one example, the operatingsoftware can provide at least method 300 of FIG. 3 .

In at least one implementation, timing service 530 directs processingsystem 550 to identify a request to monitor workflow 532 on computingsystem 500, wherein the workflow may comprise a software wizard or someother software configuration process that requires HTTP requests to atleast one web server. In response to the request, timing service 530directs processing system 550 to maintain timing information associatedwith HTTP requests to one or more web servers in association with theworkflow, wherein the timing information comprises at least timestampsassociated with initiating each of the HTTP requests and receivingresponses to each of the HTTP requests. In some implementations, thetiming information may be maintained as a log that indicates the timesassociated with initiating and ending and HTTP request.

In addition to maintaining local timing information associated with theHTTP requests for a workflow, timing service 530 further directsprocessing system 550 to obtain, from the one or more web servers, loginformation for operations initiated from the HTTP requests to the oneor more web servers, wherein the log information comprises at leasttimestamps associated with starting each of the operations and endingeach of the operations. The log information may be obtained whenrequested by computing system 500 or may be provided automatically fromeach of the one or more web servers. In some implementations, the loginformation may be provided following the completion of the workflow(e.g., last user feedback or end of the last HTTP request), however, atleast a portion of the log information can be provided prior tocompleting the workflow.

After obtaining the log information, timing service 530 directsprocessing system 550 to generate a timing diagram, wherein the timingdiagram indicates times for initiating each of the HTTP requests andreceiving responses to each of the HTTP requests, and wherein the timingdiagram further indicates times for starting each of the operations andending each of the operations. In some implementations, the display foreach of the HTTP requests may indicate child operations that werespawned in response to the HTTP request. For example, a first HTTPrequest may spawn a controller operation in the web server, which itselfspawns a method in the web server. The display may indicate that theHTTP request spawned the controller and may further indicate that thecontroller spawned the method.

In some implementations, the timing diagram may promote or identify HTTPrequests of interest or operations of interest at the one or more webservers. These events of interest may be identified based on durationsassociated with the HTTP request or operation, based on latenciesassociated with initiating the HTTP request or operation, or some otherfactor. In at least one example, the duration of an HTTP request or anoperation can be compared to a threshold value or a previous iterationof the same HTTP request or operation. When the HTTP request oroperation exceeds the threshold value or differs by threshold amountfrom the previous iteration, the HTTP request or operation can beidentified as an event of interest. Once an HTTP request or operation isidentified as being of interest, the HTTP request can be promoted withinthe timing diagram. The promotion may include a notification added tothe timing diagram indicating the HTTP request or operation, anincreased size of any duration or timing information associated with theHTTP request or operation, or some other notification in the timingdiagram. In some examples, timing service 530 directs processing system550 to provide additional information about the triggering or cause ofthe HTTP request or operation to be classified as being of interest. Theinformation may include the threshold that was exceeded, comparisons toother HTTP requests or operations, or some other information associatedwith the item of interest.

Although demonstrated as generating the timing diagram at the clientsystem with the workflow, the timing diagram may be generated by aseparate system in some examples. For example, the timing informationfrom the client may be communicated to the other computing system alongwith the log information from the web server. The information can thenbe used to generate a timing diagram.

The included descriptions and figures depict specific implementations toteach those skilled in the art how to make and use the best mode. Forteaching inventive principles, some conventional aspects have beensimplified or omitted. Those skilled in the art will appreciatevariations from these implementations that fall within the scope of theinvention. Those skilled in the art will also appreciate that thefeatures described above can be combined in various ways to formmultiple implementations. As a result, the invention is not limited tothe specific implementations described above, but only by the claims andtheir equivalents.

What is claimed is:
 1. A method comprising: identifying a request tomonitor a workflow in a client system, wherein the workflow comprises asoftware wizard; in response to the request, maintaining timinginformation associated with HTTP requests from the client system to oneor more web servers in association with the workflow, wherein the timinginformation comprises at least timestamps associated with initiatingeach of the HTTP requests and receiving responses to each of the HTTPrequests; obtaining, from the one or more web servers, log informationfor operations initiated from the HTTP requests to the one or more webservers, wherein the log information comprises at least timestampsassociated with starting each of the operations and ending each of theoperations; and generating, for display, a timing diagram based on thetiming information and the log information.
 2. The method of claim 1,wherein the operations comprise at least a controller operation and amethod operation.
 3. The method of claim 1, wherein the software wizardcomprises a wizard for configuring an application.
 4. The method ofclaim 1 further comprising: identifying one or more operations ofinterest from the operations based on the log information; and promotingportions of the timing diagram related to the one or more operations ofinterest.
 5. The method of claim 4, wherein identifying the one or moreoperations of interest from the operations is further based on one ormore duration limits associated with the operations.
 6. The method ofclaim 1, wherein the timing diagram indicates times for initiating eachof the HTTP requests and receiving responses to each of the HTTPrequests, and wherein the timing diagram further indicates times forstarting each of the operations and ending each of the operations. 7.The method of claim 1 further comprising: identifying one or more HTTPrequests of interest from the HTTP requests based on the log informationor the timing information; and promoting portions of the timing diagramrelated to the one or more HTTP requests of interest.
 8. The method ofclaim 7, wherein identifying the one or more HTTP requests of interestfrom the HTTP requests is further based on one or more duration limitsassociated with the HTTP requests.
 9. The method of claim 1 furthercomprising: monitoring one or more times associated with user feedbackin the workflow; and wherein generating the timing diagram based on thetiming information and the log information is further based on the oneor more times associated with user feedback in the workflow.
 10. Acomputing apparatus comprising: a storage system; a processing systemoperatively coupled to the storage system; and program instructionsstored on the storage system that, when executed by the processingsystem, direct the computing apparatus to: identify a request to monitora workflow in a client system, wherein the workflow comprises a softwarewizard; in response to the request, maintain timing informationassociated with HTTP requests from the client system to one or more webservers in association with the workflow, wherein the timing informationcomprises at least timestamps associated with initiating each of theHTTP requests and receiving responses to each of the HTTP requests;obtain, from the one or more web servers, log information for operationsinitiated from the HTTP requests to the one or more web servers, whereinthe log information comprises at least timestamps associated withstarting each of the operations and ending each of the operations; andgenerate, for display, a timing diagram based on the timing informationand the log information.
 11. The computing apparatus of claim 10,wherein the operations comprise at least a controller operation and amethod operation.
 12. The computing apparatus of claim 10, wherein thesoftware wizard comprises a wizard for configuring an application. 13.The computing apparatus of claim 10, wherein the program instructionsfurther direct the computing apparatus to: identify one or moreoperations of interest from the operations based on the log information;and promote portions of the timing diagram related to the one or moreoperations of interest.
 14. The computing apparatus of claim 13, whereinidentifying the one or more operations of interest from the operationsis further based on one or more duration limits associated with theoperations.
 15. The computing apparatus of claim 10, wherein the timingdiagram indicates times for initiating each of the HTTP requests andreceiving responses to each of the HTTP requests, and wherein the timingdiagram further indicates times for starting each of the operations andending each of the operations.
 16. The computing apparatus of claim 10,wherein the program instructions further direct the computing apparatusto: identify one or more HTTP requests of interest from the HTTPrequests based on the log information or the timing information; andpromote portions of the timing diagram related to the one or more HTTPrequests of interest.
 17. The computing apparatus of claim 16, whereinidentifying the one or more HTTP requests of interest from the HTTPrequests is further based on one or more duration limits associated withthe HTTP requests.
 18. The computing apparatus of claim 10, wherein theprogram instructions further direct the computing apparatus to: monitorone or more times associated with user feedback in the workflow; andwherein generating the timing diagram based on the timing informationand the log information is further based on the one or more timesassociated with user feedback in the workflow.
 19. A system comprising:one or more web servers; a client computer configured to: identify arequest to monitor a workflow in a client computer, wherein the workflowcomprises a software wizard; in response to the request, maintain timinginformation associated with HTTP requests from the client computer tothe one or more web servers in association with the workflow, whereinthe timing information comprises at least timestamps associated withinitiating each of the HTTP requests and receiving responses to each ofthe HTTP requests; obtain, from the one or more web servers, loginformation for operations initiated from the HTTP requests to the oneor more web servers, wherein the log information comprises at leasttimestamps associated with starting each of the operations and endingeach of the operations; and generate, for display, a timing diagrambased on the timing information and the log information.
 20. The systemof claim 19, wherein the client computer is further configured to:monitor one or more times associated with user feedback in the workflow;and wherein generating the timing diagram based on the timinginformation and the log information is further based on the one or moretimes associated with user feedback in the workflow.